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Dandelion Booting 
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The initialization of the system state 
(control store, main memory, IOP 
memory, etc.) to that required before 
the first software instruction (Mesa 
opcode) can be executed (the so-calle 
Prin cOps Boot State) 



• Boot Stages 
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Software 
Boot 



Press Boot 
Button 



Begin instruction 
execution 



PrincOps 
Boot state 



Begin execution 
of software boot 
file 
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PrincOps Boot State 

Operational CP microcode and IOP 
control code is loaded into control store 
and IOP memory 

Pilot Boot File loader (Germ) has been 
loaded into the appropriate place in 
main memory 

I/O Page has been mapped to its 
assigned virtual address 

All other normal real memory (i.e. 
excluding display bank and VM map) 
has been mapped 

The Mesa emulator has been prepared 
to execute the first Mesa byte code of 
the Germ 
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Hardware Boot 

reset the hardware 

put the CP in a Wait state 

cause the IOP to start execution at a specific 

address in IOP memory 

"Microcode Boot" 

consists of multiple phases 

saves EProm space 
a!lows more flexibility with changes 
overlays "one time" boot code 
provides a powerful diagnostic strategy 

function: 

delivers Mesa and I/O microcode to control store 
delivers IOP control program (Domino) to IOP memory 
delivers Germ to main memory 
initializes the VM map, and Mesa emulator 

- runs PreBoot diagnostics 

- source of boot files: EProm and Boot Device 
allows selection of: 

Boot Device; rigid disk, floppy disk, Ethernet (2 sources) 
Boot Mode: normal boot or diagnostic boot 



EProm contents 

PreBoot diagnostics 
IOP boot code 

Phase 0 CP microcode boot file 
IOP interrupt links 



Boot concepts 

Boot files and boot blocks 
Processing boot files 
CP execution states 
- CP kernel and CP protected areas 



Boot files 
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name: *.db 

a series of boot blocks, together with a checksum 

boot blocks vary in length 

structure: 



Boot Block 




Boot Block 










Block Header 


Boot Block 




Block Body 


1 

1 1 


^--^ 

^---^ 




Boot Block 







Checksum 



Block Header indicates type of block: 



Type 








— ► 


Type = 0: special block 
Type # 0: control store block 



types of boot blocks: 
control store 
special 

task program counter (IPC) 
U register 
IOP memory 
ignore 

start IOP address 
last block 

- examples of boot blocks: 



Control store block 



TPC block 



IOP memory block 



CS address 



low word of instr. 



middle word of instr. 



high word of instr. 



low word of instr. 



middle word of instr. 



high word of instr. 



n = [1 ..15] 



0 



0 



X 



TPC value 



t = [0 .. 7] 



Last block 



8 



Last block flags 



0 | X 


9 


IOP address 


Count (bytes) 


byte 1 


byte 0 


byte 3 


byte 2 
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© Processing boot files 

unpack the boot blocks, i.e. load the data into the 
appropriate part of the Dandelion hardware 
special precautions are needed to process the 
control store and TPC boot blocks 

® CP execution states 

Run state: CP is executing in multitask fashion 
Stopped state: CP is executing in kernel task (7) 
Wait state: CP is not executing 

© CP kernel 

Special CP microprogram that executes while the 
CP is in the " stopped" state 
Can communicate with IOP 
Performs memory refresh 
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Microcode Boot Phases 
Phase 0 

Run PreBoot diagnostics (IOP) 
Determine boot device (IOP, CP) 

- Process "PhaseO.db" (from EProm) boot file (IOP) 

Phase 1 

- Start CP execution of "PhaseO" microcode (IOP) 

=> Load "Initial.db" boot file (from Boot device) 
into main memory (CP) 

Process "Initial.db" (from main memory) file (IOP) 

Phase 2 

- Start CP execution of "Initial" microcode (IOP) 

=> Load "Mesa.db" boot file (from Boot device) 
into main memory. This contains Mesa and I/O 
microcode, and Domino code (CP) 

=» Load the Germ into main memory (CP) 

=> Initialize the VM map (CP) 

=> initialize the Mesa emulator (CP) 

Process "Mesa.db" (from main memory) file (IOP) 



Transfer to Software booting 



Start CP execution of Mesa, I/O microcode (IOP) 
=> Germ software starts executing (CP) 
Transfer to start of Domino code (IOP) 
=> Domino software starts executing (IOP) 

Boot files location (rigid disk booting) 

PhaseO boot file: located in EProm 

Initial boot file: located at fixed location on disk # 
stored in consecutive sectors [cyl 0, hd 1, sec 0 on] 

- Physical Volume Root Page(PVRP): 

points to rest of boot files 

located at fixed location on disk [cyl 0, hd 0, sec 0] 
contains pointers to: 

-> Mesa microcode boot file 
->Germ boot file 
-h> Diagnostic boot file 
Software boot file (e.g. Othello) 



Protected areas in CP 



- Control store and TPC images 

Low 128 locations in control store contain CP "vital" functions 
of IOP task code, memory refresh code, trap-catcher code, 
loop code 

Image of protected control store area is kept in IOP memory 
Image of TPC values is kept in IOP memory 
Images are transferred to CP at end of boot phase 
Writing control store and TPC values requires CP to be 

stopped AND requires careful CP-IOP interaction to avoid 

losing memory refresh 

Kernel microcode is never overlaid (32 locations) 



Detailed description of rigid disk booting 
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IOP 



Phase 0 



Initialize 
Run PreBoot diagnostics 
Process PhaseO.db 
Transfer CS image 
Transfer TPC image 
Start CP kernel 

Start CP 
Determine boot device 



CP 



I 



CP kernel executes 



->~l CP exits kernel (to Run state) 
->~ Determine boot device 



Phase 1 



Wait for Flag 



Process Snitial.db boot file 
(from main memory) 

Stop CP 

Transfer control store and 
TPC images 

Start CP 
[Start IOP] 



Read Initial.db from disk 
to main memory 
Set Flag in main memory 

Loop in protected area 



CP enters kernel 



CP exits kernel (to Run state) 



Phase 2 



Wait for Flag 



Process Mesa.db boot file 
(from main memory) 

Stop CP 

Transfer control store and 
TPC images 

Start CP 
Start IOP 



Read Mesa.db from disk 
to main memory 
Read Germ from disk to memory 
Initialize VM map, Mesa emulator 
Set Flag in main memory 

Loop in protected area 
CP enters kernel 



CP exits kernel (to Run state) 



Domino executes 



Mesa emulator executes the Germ 



Other topics 
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® Floppy booting 

Similar structure to rigid disk booting except that 
the boot device is directly accessible from the IOP 
The IOP processes boot files directly from the 
floppy disk 

® Ethernet booting (Etherbooting) 

Similar structure to rigid disk booting 

Boot files are fetched from boot server over the 
Ethernet 

© Diagnostic booting 

Allows the repeated execution of a collection of 
special boot diagnostics 

Diagnostics have total control of machine, but 
use the boot code to fetch and process boot files 

Implemented by repeating Phase 2 multiple times 
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Appendix 
@ Alternate boot codes 

AltBoot code Type of boot 

0 rigid* (diagnostic) 

1 rigid* 

2 floppy 

3 ethernet 

4 ethernet (diagnostic) 

5 floppy (diagnostic) 

6 alternate ethernet 

7 Trident 1 (diagnostic) 

8 Trident 2 (diagnostic) 

9 Trident 3 (diagnostic) 

10 floppy cleaning 



* AltBoot 0 and 1 apply to the Shugart 1 004, SA4008, 
Quantum, or Trident 0 disk, whichever is installed in 
the system 



